Software code typically is executed in a context. As used herein with respect to executing software code, a “context” is a situation, circumstance and/or environment, in terms of software and/or other elements of a computer system, in which software code is executed. A context is typically defined by various combinations of the following: values of variables on a stack; the parameters passed to a function; global and/or static variables; the credentials of the process and/or the thread in which the software code is executed; evidence of the code (e.g., the author of the code; where the code is being loaded from, etc.); associated tokens of the process (e.g., the user under whose credentials the process is running); environmental variables of the environment under which the software is running; granular permissions granted by the execution engine; the machine on which the code is running; and other items.
Software code (often referred to herein as simply “code”) running in a given context might need to change to a different context to accomplish its programmed task. A change to a different context is often refined to herein as a “context switch.” For example, a user under which a process is running could be a machine administrator, but the execution engine decides to deny the file I/O permissions based on the identity of the code it is running. Identity of the code is typically determined by the author of the code, where it is downloaded from, etc. For example, an administrator running a web page may download a piece of software from the Internet. Even through the user's access permissions allow reads and writes of the file system (e.g., because she is an administrator on the machine), the execution engine could determine that the software downloaded is from a third party and the third party cannot be established as “trusted.” Thus, the execution engine can prevent the download software from accessing the file system. In a Common Language Runtime (CLR) environment, this prevention is achieved through the code access permissions (CAS) subsystem.
A software application is sometimes artificially separated from one or more of its components because the components need to run in different contexts. For example, consider a software application that has a user interface component that runs under the interactive user account and a “daemon” or “service” component that runs under the system account. Perhaps the software application designer separated these components because the “service” needs to operate under “system” account so that it can run at a higher privilege than the user interface component that runs under interactive user. A software developer must develop code to establish communication channels between the interactive component and the service component, and manage the data that is sent back and forth.
For example, consider the pseudo-code 100 in FIG. 1. Pseudo-code portion 102 requires a higher privilege and/or more trust than the remainder of the pseudo-code, and may need to run in a different process and perhaps on a different machine. It is also conceivable that the code requires lower privileges or lower trust and needs to run in a different application domain in the same process—perhaps for security reasons. Thus, there is a need to implement a context switch.
In order to actually code the pseudo-code 100 to implement a context switch using known technologies (e.g., .NET remoting, Simple Object Access Protocol (SOAP), Component Object Model (COM), Remote Procedure Call (RPC), etc), programmers need to do one or more of the following:                1. Package the code portion 102 into a different process, assembly and/or module;        2. Load the module into the required process and/or application domain;        3. Set up some kind of inter/intra process communication to send the parameters to the required process and/or application domain and get the results back; and        4. Harvest the results.        
FIG. 2 illustrates an example of one known solution 200 for programming a context switch. Solution 200 includes two pseudo-code portions 200 and 206 to be executed in different contexts. Portion 200 includes a function call 204 to portion 206, which may be part of a separate application domain, package and/or assembly, and may be configured to execute as part of a separate process or thread, and may reside on a different computer or computer component.
A non-trivial amount of code needs to be written to implement the execution of code portions 200 and 206 in separate contexts. First, portions 201 and 206 must be created as two separate and distinct entities, e.g., an object and a function called from within the object as shown in FIG. 2. Portion 201 must be configured illustrated by pseudo-code 202) to repackage communication code and set-up channels, and may be configured to convert arguments into different data types, before calling portion 206. Further, the call itself (204) must be coded, as does the harvesting of the results from the call.
Programming such context switches not only disrupts the flow of programming, but requires knowledge of the specific technologies involved in doing so. Further, the programming of context switches tends to be repetitive and serves no direct purpose in realizing the logic of the application for which it being used. Developers or programmers (hereinafter “programmers”) often must write such code, which is an inefficient use of their time and reduces their productivity.